In information technology, backup refers to the copying of data so that these additional copies may be restored after a data loss event. Backups are useful primarily for two purposes: to restore a computer to an operational state following a disaster (called disaster recovery) and to restore small numbers of files after they have been accidentally deleted or corrupted. Backups differ from archives in the sense that archives are the primary copy of data and backups are a secondary copy of data. Backup systems differ from fault-tolerant systems in the sense that backup systems assume that a fault will cause a data loss event and fault-tolerant systems assume a fault will not. Backups are typically that last line of defense against data loss and consequently the least granular and the least convenient to use.
Since a backup system contains at least one copy of all data worth saving, the data storage requirements are considerable. Organizing this storage space and managing the backup process is a complicated undertaking.
Any backup strategy starts with a concept of a data repository. The backup data needs to be stored somehow and probably should be organized to a degree. It is able to be as simple as a sheet of paper with a list of all backup tapes and the dates they were written or a more sophisticated setup with a computerized index, catalog or relational database. Different repository models have different advantages. This is closely related to choosing a backup rotation scheme.
An unstructured repository may simply be a stack of floppy disks or CD-R media with minimal information about what was backed up and when. This is the easiest to implement, but probably the least likely to achieve a high level of recoverability.
A Full plus Incremental repository aims to make storing several copies of the source data more feasible. At first, a full backup (of all files) is taken. After that an incremental backup (of only the files that have changed since the previous full or incremental backup) is taken. Restoring whole systems to a certain point in time would require locating the full backup taken previous to that time and all the incremental backups taken between that full backup and the particular point in time to which the system is supposed to be restored. This model offers a high level of security that something is able to be restored and is able to be used with removable media such as tapes and optical disks. The downside is dealing with a long series of incrementals and the high storage requirements.
A Full plus Differential backup differs from a Full plus Incremental in that after the full backup is taken, each partial backup captures all files created or changed since the full backup, even though some may have been included in a previous partial backup. Its advantage is that a restore involves recovering only the last full backup and then overlaying it with the last differential backup.
A Minor plus Reverse Incrementals repository is similar to a Full plus Incrementals repository. The difference is instead of an aging full backup followed by a series of incrementals, this model offers a mirror that reflects the system state as of the last backup and a history of reverse incrementals. One benefit of this is it only requires an initial full backup. Each incremental backup is immediately applied to the minor and the files they replace are moved to a reverse incremental. This model is not suited to use removable media since every backup must be done in comparison to the minor.
A continuous data protection model takes backup a step further, and instead of scheduling periodic backups, the system immediately logs every change on the host system. This is generally done by saving byte or block-level differences rather than file-level differences. It differs from simple disk minoring in that it enables a roll-back of the log and thus restore of old image of data.
Deciding what to back up at any given time is a harder process than it seems. By backing up too much redundant data, the data repository will fill up too quickly. If enough data is not backed up, critical information is able to get lost. The key concept is to only back up files that have changed.
Copying the file system that holds the files to be backed up to another location is one option. This usually involves unmounting the file system and running a program like dump. This is also known as a raw partition backup. This type of backup has the possibility of running faster than a backup that simply copies files. A feature of some dump software is the ability to restore specific files from the dump image.
Some file systems have an archive bit for each file that says it was recently changed for copies of only changed files. Some backup software looks at the date of the file and compares it with the last backup, to determine whether the file was changed. Block level incremental copying is a more sophisticated method of backing up changes to files by only backing up the blocks within the file that have changed. This requires a higher level of integration between the file system and the backup software.
A versioning file system keeps track of all changes to a file and makes those changes accessible to the user. Generally this gives access to any previous version, all the way back to the file's creation time. An example of this is Wayback for the Linux OS.
If a computer system is in use while it is being backed up, the possibility of files being open for reading or writing is real. If a file is open, the contents on disk may not correctly represent what the owner of the file intends. This is especially true for database files of all kinds.
When attempting to understand the logistics of backing up open files, one must consider that the backup process could take several minutes to back up a large file such as a database. In order to back up a file that is in use, it is vital that the entire backup represent a single-moment snapshot of the file, rather than a simple copy of a read-through. This represents a challenge when backing up a file that is constantly changing. Either the database file must be locked to prevent changes, or a method must be implemented to ensure that the original snapshot is preserved long enough to be copied, all while changes are being preserved. Backing up a file while it is being changed, in a manner that causes the first part of the backup to represent data before changes occur to be combined with later parts of the backup after the change results in a corrupted file that is unusable, as most large files contain internal references between their various parts that must remain consistent throughout the file.
A snapshot is an instantaneous function of some storage systems that presents a copy of the file system as if it was frozen in a specific point in time, often by copy-on-write mechanism. Quiescing to consistent state (e.g. closing all files) for a short time, taking a snapshot, then resuming data change process and running the backup on the snapshot is an effective way to work around this problem. A snapshot itself is hardly a backup, as it does not protect from disk hardware failure.
Many backup software packages feature the ability to backup open files. Some simply check for openness and try again later.
For cold database backup, during a cold backup the database is closed or locked and not available to users. All files of the database are copied (image copy). The data files do not change during the copy so the database is in sync upon restore.
Some database management systems offer a means to generate a backup image of the database while it is online and usable (“hot”). This usually includes an inconsistent image of the data files plus a log of changes made while the procedure is running. Upon a restore, the changes in the log files are reapplied to bring the database in sync.
Not all information stored on the computer is stored in files. Accurately recovering a complete system from scratch requires keeping track of this non-file data also. System specifications are needed to procure an exact replacement after a disaster. Each file's permissions, owner, group, ACLs, and any other metadata need to be backed up for a restore to properly recreate the original environment. The layout of the original disk, as well as partition tables and file system settings, is needed to properly recreate the original system. The boot sector is able to sometimes be recreated more easily than saving it. Still, it usually is not a normal file and the system will not boot without it.
It is frequently useful to manipulate the backed up data to optimize the backup process. These manipulations are able to improve backup speed, restore speed, data security, and media usage. Various schemes are able to be employed to shrink the size of the source data to be stored so that less storage space is used. Compression is frequently a built-in feature of tape drive hardware or other storage hardware.
When multiple similar systems are backed up to the same destination storage device, there exists the potential for much redundancy within the backed up data. For example, if 20 Windows® workstations were backed up to the same data repository, they might share a common set of system files. The data repository only needs to store one copy of those files to be able to restore any one of those workstations. This technique is able to be applied at the file level or even on raw blocks of data, potentially resulting in a massive reduction in required storage space.
Sometimes backup jobs are duplicated to a second set of storage media. This is able to be done to rearrange the backup images to optimize restore speed, to have a second copy for archiving in a different location or on a different storage medium.
High capacity removable storage media such as backup tapes present a data security risk if they are lost or stolen. Encrypting the data on these media is able to mitigate this problem, but presents new problems. First, encryption is a CPU intensive process that is able to slow down backup speeds. Second, once data has been encrypted, it is able to not be effectively compressed (although since redundant data makes cryptanalytic attacks easier many encryption routines compress the data as an integral part of the encryption process). Third, the security of the encrypted backups is only as effective as the security of the key management policy.
Sometimes backup jobs are copied to a staging disk before being copied to tape. This is able to be useful if there is a problem matching the speed of the final destination device with the source system as is frequently faced in network-based backup systems.
Many backup programs make use of checksums or hashes to validate that the data was accurately copied. These offer several advantages. First, they allow data integrity to be verified without reference to the original file: if the file as stored on the backup medium has the same checksum as the saved value, then it is very probably correct. Second, some backup programs are able to use checksums to avoid making redundant copies of files, to improve backup speed. This is particularly useful for the de-duplication process.